.NET Core CLi
.NET Core 的專案目錄結構
.NTE Core 生命週期
上一篇概略性的提到 .NET Core的差異還有列出幾個類型的開發專案方式
以及簡單的示範個專案Hello World
今天來整理一下 .NET Core之後所支援的Cli, 並利用Cli 建立一個MVC專案, 以及了解整個生命週期
熟悉前端框架的朋友一定對CLI不陌生
Command-line Interface :就是用Command-linen所設計的一個介面,可以讓使用者透過鍵盤輸入這些指令去執行以往需要用到滑鼠或是IDE裡面去執行的事情,並透過CLI可以建立一個現有的範本專案,並將相關需要的library一次載入,增加開發效率
來到2020的.NET也為了 .NET Core推出支援的CLI,在操作上又更加的方便,以下就會示範如何在Mac上使用 .NET CLI去建置一個MVC的專案
.NET Cli 在安裝VS2019 for Mac 時就已經包含在 .NET Core裡面了
所以如果是使用VSCode的朋友,必需要安裝 .NET Core SDK才有辦法開發 .NET Core(已經包含Cli)
以下是使用Cli建立一個叫做DotnetMvc 專案的指令
Dotnet new mvc -n DotnetMvc
//mvc為固定的專案範本名稱,註1
//-n 表示專案的名稱,也可以手動建立folder可直接省略這段
Dotnet build
Dotnet run
在這裡筆者心裡有兩個疑問
但目前看起來官網是沒有提供的這些功能,建議還是配合IDE使用會比較方便
註1.
關於專案類型的指令,可以參考官網說明
使用Cli主要是可以透過指令快速的建立及執行處理專案的動作
目前微軟還是陸續在更新相關的指令,都可以在官網上找到更新的文件
(我想微軟最大的好處就是文件更新的算快了,也有一個龐大的資料庫在那邊)
詳細的Cli指令請點我
第一眼看到 .NET Core專案覺得差異最大的就是專案沒有web.config
取而代之的是appsettings.json,這邊針對幾個設定檔去做整理
.
.net Core將以往的web.config拿掉,不再使用舊有的xml格式
組態設定改用json格式為基準
先來看一下以cli所建立的專案
預設的appsettings.json如下
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"AllowedHosts": "*"
}
"AllowedHosts": "example.com"
啟動專案則會顯示400 Bad Request.
其中設定是可以用分號隔開的,如果新增一組localhost,是符合規定的
頁面則會成功顯示
"AllowedHosts": "example.com;localhost"
此外包含設定DB的connect string、config參數,也是在這裡新增
.NET Core 因為不再使用config的組態設定,意味者ConfigurationManager已經不能再使用了,必須透過DI的方式去管理
如何切換正式/測試環境設定
使用cli建立的mvc專案,除了appsettings.json,另一個是appsettings_appsettings.Development.json,這支檔案依附在appsettings.json的下方,讀取時都會一起讀取,如果要區分開發環境及正式環境,參數兩邊都要設定
使用cli執行,沒有特別設定在launchSettings,預設會是抓最上層的appsettings.json的設定,也就是production
在使用cli時同時也會建立下方的設定到launchSettings.json,執行時會去認commandName為project的參數,去決定只讀取哪一個設定檔
這個設定檔不是必要的檔案,只有在開發環境時才會需要使用到,部署到正式環境時並不需要這個設定,根據所使用的server去做相關的環境設定
.NET Core 調整了進入程式的起始點,不使用繼承方式而改用DI的方式注入,坦白說一開始看到還覺得很像console app,但整體程式碼個人覺得較簡潔
在所有介紹 .NET Core的文章都可能會有這一段程式碼
也就是整個應用程式的進入點
先來看看這一行程式碼
CreateHostBuilder(args).Build().Run();
透過CreateHostBuilder()回傳的物件去實作IHostBuilder這個介面,去執行Build()和Run()的方法
接下來在CreateHostBuilder()裡面會去執行ConfigureWebHostDefaults,主要是去建立及初始化一個HostBuilder的實體,接下來透過UseStartup()方法去執行相關的類別,在這裡就是去執行Startup.cs這支程式
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
分成以下兩部分
ConfigureServices
透過Dependency Injection的方式,註冊相關的服務
比較一下個專案範本所使用的服務也不同
例如Razor pages專案裡所使用的服務就跟MVC下圖的不相同
Configure
在這個方法裡面,透過IApplicationBuilder使用pipeline的方式去將這些middleware components執行,不論事Razor pages或是MVC,初始所設定的middleware都相同,只差在最後UseEndpoint會針對特性去做調整
整個Configure直執行的順序如下,接下來也會針對Middleware去做整理,通常客製化的Middleware都會放在Endpoint前
(圖片來源:https://docs.microsoft.com/)
IWebHostEnvironment 是當程式停止時,可以使用這個介面去監聽
值得注意的是,這個interface在 .NET Core 3.0之後有做調整,而非前幾版的IApplicationLifetime.
今天就先到這裡
如果敘述或了解錯誤的地方還請留言多指教
參考資料:
https://dotnettutorials.net/lesson/asp-net-core-satrtup-class/
https://blog.johnwu.cc/article/ironman-day02-asp-net-core-application-lifetime.html
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.1